I am a little surprised that nothing else than the sitemap syntax needs to be updated.
But if that is really the case, that us great.

I am a little surprised that nothing else than the sitemap syntax needs to be updated.

I was surprised as well. But all the required code is automatically generated from the syntax, and that just works. There is more additional code for Basic UI in the webui repository, but still not a lot.

An update of the documentation will of course be required.

Of course.
Looking at the documentation, I can do the minimal change, or go through the sitemap documentation and do a more thourough update. E.g. documentation for the chart element talks about begin and end parameters that do not exist, there are links to wiki's on archived repositories for examples, and I feel the warning about preference for main UI is maybe worded a bit too strong. I think it is irrelevant it cannot be shown inside main UI, but it still can be configured there.

I think it is irrelevant it cannot be shown inside main UI

You can access BasicUI (and other UIs) from MainUI through the "icon at top right" (don't know how it is properly described).

I have created a minimal documentation update, and will keep a broader update for later.

Great @mherwege !

If you could add support for DateTime input as well, I think many users will be happy as it then allows for simple scheduling of tasks (in combination with a rule).

support for DateTime input

Next on my list, but will be in another PR, and not sure how to do it yet. Material Design Lite does not have a pre-defined calendar and time input widget, and the default html data/time entry is not very good. In the main UI, that could be solved with a vue datepicker, but that's not an option here. I think it will have to be another input type to make it easier to handle in the mobile apps, where better support is available.

I think it will have to be another input type to make it easier to handle in the mobile apps, where better support is available.

No reason to do that, we (as in: mobile apps people) can check the item type for choosing the correct widget.

@maniac103

No reason to do that, we (as in: mobile apps people) can check the item type for choosing the correct widget.

That’s great. What about a parameter for date/time? In some cases, the time is the only thing to be updated (e.g. to update a daily schedule). Other cases you may only want to update the date. So I would thing there needs to be a parameter for that. What do you think?

What about a parameter for date/time? In some cases, the time is the only thing to be updated (e.g. to update a daily schedule). Other cases you may only want to update the date.

That may be a good idea. In the case of the Android app, there's no date/time picker in Material Design 3 anyway, just date pickers and time pickers, but still, with an appropriate hint one could show either one, or both.
WHen introducing such a thing, my suggestion would be to keep the parameter as a generic string (inputHint or something like that?), so it's possible to have different types of hints for different types of input fields if needed at some later point.

Since that is essentially content description of the item it should be handled in item metadata.

Since that is essentially content description of the item it should be handled in item metadata

IMHO it isn't. It's presentation, similar to e.g. Slider min/max/step values, where one could argue to use the item's min/max/step values. The same thing here: why should there only be one possible presentation for a given item and not the choice of keeping date/time combined in one place and keeping it separate in another? A similar thing exists for Sliders, where people want different behaviors (apply during dragging vs. apply on release), but using item metadata for that is conceptually wrong because the option is about the presentation layer, not the item.

Should it be possible to change the unit of measurement of Number items, e.g. should the user be able to change 20 °C to 30 F? If not mobile apps could display a numeric keyboard which makes it easier to enter numbers, but makes it impossible to enter anything else, like units.

The implementation in Basic UI allows changing the UOM. And Basic UI does not impact keyboard layout on mobile. This might be another candidate for an inputHint value. If set to number or no UOM present in the numeric value, it would present a numeric keyboard, if not, present a default keyboard.

For information
@openhab/webui-maintainers
@openhab/android-maintainers
@openhab/ios-maintainers

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/documentation-highlight-the-changes-between-version-3-4-4-and-4-0/147801/1